In the context of wireless communication networks based on Third Generation Partnership Project (3GPP) Technical Specifications, a device that is configured for Machine Type Communication (MTC) through a 3GPP network with an MTC Server or other machine type devices is referred to as a “machine type device,” or, equivalently, an “MTC type device.” More than one machine type device may be represented by one 3GPP User Equipment (UE), in the sense that the UE may act as a gateway or router for multiple machine type devices that are communicatively connected through the UE and/or the UE may run multiple MTC applications or services, each representing a logically different machine type device. Further in this context, the MTC Server will be understood as a type of “Services Capability Server” or SCS.
3GPP is currently investigating enhancements for machine type devices in Release 12 of the controlling 3GPP Technical Specifications.
While machine type devices are characteristically expected to have low mobility (in most but not all cases) and to engage in infrequent or low date rate communication, there is also an expectation that potentially vast numbers of machine type devices will be linked to MTC services or other machine type devices through a supporting 3GPP network. Consequently, even if each machine type device generates a relatively small amount of signaling, traffic associated with MTC services may impose significant loading on the network.
In one aspect of supporting MTC within the 3GPP network context, 3GPP Release 11 defined a new identifier, referred to as the “External Identifier.” The External Identifier is specified in 3GPP TS 23.003. Other Technical Specifications of interest include: 3GPP TS 23.401 v11.1.0, 3GPP TS 23.888 v1.6.1, 3GPP TS 23.682 v11.0.0, 3GPP TS 22.368 v11.4.0
A 3GPP UE with one International Mobile Subscriber Identity (IMSI) may have one or several globally unique External Identifier(s) that are stored in the associated “user subscription” within the Home Subscriber Server or HSS in the associated user's home network. The intention is that each External Identifier can be used to identify a particular one of the machine type devices associated with the UE. However, it should be noted that use of External Identifiers is not restricted to MTC applications.
With the above usage of External Identifiers, a single 3GPP UE is associated with more than one External Identifier, in dependence on the number of machine type devices it is associated with. These identifiers have meaning within the “machine domain,” meaning that they are used to identify machine type devices for purposes of MTC services. However, as far as the 3GPP network is concerned, an associated International Mobile Subscriber Identity or IMSI identifies the UE for purposes of 3GPP bootstrapping. Here “3GPP bootstrapping” refers to the process of the UE attaching to the 3GPP network, which involves authenticating and authorizing the UE, for establishing the connection and its associated radio bearers.
Those of ordinary skill in the art will recognize that a 3GPP UE is associated with an owner or other authorized user—generically referred to as a “user”—and that the user in general will have had to establish a user subscription with a particular 3GPP network operator. The 3GPP network associated with the subscription is referred to as the user's “home network” and that network will include a Home Subscriber Server (HSS) or equivalent, which securely stores user subscriptions, including the associated IMSIs, for use in 3GPP bootstrapping of UEs attempting to connect to the home network directly, or UEs connecting to visited networks, wherein the visited networks communicate back to the home network for authorization, billing, etc.
Consequently, there are two types of subscriptions at issue regarding MTC services running on a 3GPP UE: (1) 3GPP network or “user” subscriptions, and (2) MTC service subscriptions. For a given UE, its associated 3GPP network subscription must be active and validated before the UE is permitted to attach to the 3GPP network and establish radio bearers for communication services, including any MTC services. However, to the extent that the UE supports one or more machine type devices, engaging in MTC services requires not only successful attachment and coupling through the 3GPP network, but also activation and/or validation of one or more associated MTC service subscriptions.
Currently, in 3GPP Release 11, there is an assumed static relationship between the External Identifiers used by the MTC service provider(s) to identify the machine type devices associated with a UE. Because the IMSI associated with the UE is not provided externally, it is expected that the Home Subscriber Server (HSS) or equivalent entity in the user's home 3GPP network will store the External Identifiers in the associated user subscription, along with the IMSI. However, the mechanisms used for activation and/or deactivation of MTC subscriptions and MTC features lie outside the scope of 3GPP.
Such an approach consequently imposes significant provisioning burdens from the perspectives of the 3GPP network operators and the MTC service providers. One problematic aspect is that 3GPP network operators understandably safeguard IMSIs as a matter of network integrity and fraud prevention, and generally do not make IMSIs available to external service providers, including MTC service providers. Consequently, MTC Servers generally do not have access to IMSIs as a means of identifying UEs involved in the MTC services they support, nor do HSSs within 3GPP networks have any mechanism for associating External Identifiers with a particular IMSI, absent potentially burdensome manual provisioning of such associations.
Such provisioning can be prohibitively burdensome because there may be many External Identifiers for individual UEs, given that one UE may have multiple machine type devices associated with it. As a further complication, External Identifiers may be added, modified, or deleted, for a given UE, reflecting MTC service changes. Still further, when a UE attaches to a 3GPP network, as identified by the associated IMSI, it may or may not want to activate all of the MTC services associated with it.
For example, a UE embedded in a vehicle has one IMSI associated with it, for 3GPP Bootstrapping, such as stored in a Subscriber Identity Module (SIM) or software-based Universal SIM. Yet this one UE may have multiple machine type devices associated with it, which correspondingly subscribe to many services, e.g. local tourist information, car software updates, car maintenance on-line checking, car emergency service notifications, web music push services, etc. At the outset of a trip, not all services should necessarily be activated. Conversely, when arriving at the trip destination, local tourist information may be necessary or at least highly desirable, which requires the activation of a corresponding service. Further along these lines, it may be desirable to deactivate all but one or two specialized services when the car is parked. As an example, vehicle software updates and car maintenance services (telematics) may be activated during the time that the car is parked.
Of course, the UE may perform an MTC registration procedure towards each of the services, and the corresponding MTC Server(s) shall try to reach the UE only for registered services. However, registration does not necessarily mean the service is always active from the UE side. Further, some services may not have any registration procedure.
FIG. 1 illustrates the 3GPP Architecture for supporting MTC services, which are also referred to as Machine-to-Machine or M2M services. Consequently, unless otherwise noted, the term “M2M” and “MTC” may be used interchangeably herein.
One sees a Visited Public Land Mobile Network (VPLMN) 10 and a Home Public Land Mobile Network 12 and in this example, a given UE 14 attaches to the VPLMN 10 and the VPLMN 10 communicates with the HPLMN 12 for authorization, etc. The UE 14 includes or is otherwise associated with one or more machine type devices 16, which may be M2M applications hosted on the UE 14 in a non-limiting example case. In this disclosure, machine type devices 16 are also referred to as MTC devices and/or M2M devices, and, unless otherwise noted, the reader may assume that all such terms imply a device that engages in MTC with one or more entities in the machine domain based on establishing access through a 3GPP or other such wireless communication network, e.g., the VPLMN 10 and/or HPLMN 12 shown in the diagram.
The VPLMN 10 includes a Radio Access Network (RAN) 20 having one or more of the following entities: a Mobile Switching Center (MSC) 22, a Mobility Management Entity (MME) 24, a Serving GPRS Support Node (SGSN) 26, and a Serving Gateway (S-GW) 28. Here, it will be appreciated that particular arrangement and naming convention of the entities depicted in the VPLMN 10 will depend on the particular specifications of the network, e.g., 3GPP Release 8, 9, 10, 11, etc.
The same is true for the HPLMN 12, which in this example diagram includes: a Gateway GPRS Support Node/Packet Gateway (GGSN/P-GW) 30, an HSS 32, a Machine Type Communication InterWorking Function (MTC-IWF) 34, a Charging Data Function/Charging Gateway Function (CDF/CGF) 36, a Short Message Service Service Center/Gateway Mobile Switching Center/Interworking Mobile Switching Center (SMS-SC/GMSC/IWMSC) 38, which may be associated with an IP Short Message Gateway (IP-SM-GW) 40 and a Short Message Entity (SME) 42.
The above entities may be regarded as being in or associated with the wireless communication network operator's domain—the network domain. One also sees a machine domain, which may be understood as being the domain of the M2M service provider. In the illustrated example, the machine domain includes a Services Capability Server (SCS) 50, which is also referred to as an MTC Server or an M2M Server. Further, one or more M2M Application Servers (AS) 52 will be understood as hosting or otherwise providing one or more M2M applications that are intended to use or otherwise interact with the machine type device(s) 16 in the depicted UE 14 (and, in general, with essentially any number of machine type devices 16 hosted or associated with a potentially large number of UEs 14).
In the example, one sees an AS 52-1 coupled to the MTC Server 50, and another AS 52-2 coupled to the GGSN/P-GW 30 in the network domain. The former coupling represents an example of the “Indirect Model” denoted with the encircled numeral “1” in the diagram, while the latter coupling represents an example of the “Direct Model” denoted with the encircled numeral “2” in the diagram. A combination of these models is referred to as the “Hybrid Model.”
As seen in the figure, the interface Tsp is between the SCS 50 and the MTC-IWF 34. The Tsp interface is defined for the triggering function only, e.g., where the machine domain triggers communication with an MTC device 16 through the 3GPP network(s) 10, 12. The triggering function is based on the assumption that the External Identifier for the targeted MTC device 16 is already configured in the corresponding UE subscription in the HSS 32. When triggering is needed, the SCS 50 sends a triggering message that contains the External Identifier of the device 16 to the MTC-IWF 34. The MTC-IWF 34 translates the received External Identifier to the corresponding UE IMSI, based on querying the HSS 32 over the S6m interface. The MTC-IWF 34 will then send the triggering message with the IMSI over the T4/T5 interface(s).